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ABSTRACT 


The  volatility  in  today’s  economics  has  resulted  in  government  attempts  to  reduce  cost 
while  maintaining  performance.  One  of  the  elements  examined  by  the  Defense  Advanced 
Research  Projects  Agency  was  the  idea  of  fractionating  a  current  monolithic  satellite 
system  into  several  smaller,  space-based  group  (SBG)  satellites.  This  architecture  would 
allow  for  multiple,  smaller,  and  less  expensive  satellites  to  work  together  to  accomplish 
the  several  missions. 

This  study  focused  on  research  and  analysis  of  the  system  FireSat.  The  analysis 
removed  the  ground  communications  suite  from  the  sensor  platform.  A  Microsoft  Excel 
spreadsheet  was  used  to  develop  the  resulting  cost  relation  for  the  sensor-only  satellite. 
Using  assumptions  provided  by  that  analysis,  three  additional  systems,  currently  in 
operation,  were  examined  for  cost  savings  if  placed  into  the  SBG.  The  Tracking  and  Data 
Relay  Satellite  was  used  as  a  basis  for  cost  of  a  communications  satellite.  The  cost 
analysis  resulted  in  an  estimated  $52  million  FY15  to  the  space  segments  alone. 
Additional  research  is  required  to  determine  cost  savings  within  the  full  architecture  and 
develop  a  risk-cost  analysis  to  detennine  whether  cost  could  be  further  reduced  due  to 
higher  reliability,  lower  replacement  cost  risk,  and  longer  lifetimes. 
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I.  INTRODUCTION 


Since  the  launch  of  Sputnik  1  in  1957,  the  nations  of  the  world  have  researched 
and  designed  spacecraft  to  perfonn  a  variety  of  services  while  in  orbit.  These  missions 
range  from  weather  monitoring  to  worldwide  communications.  Technology  has  advanced 
rapidly  in  the  past  half-century,  and  this  has  led  to  increased  requirements  placed  upon 
orbital  systems.  These  requirements  have  resulted  in  a  transition  from  a  singular  mission 
based  system  into  a  platform  capable  of  facets  of  different  missions,  all  executed 
concurrently.  These  coupled  requirements  have  given  rise  to  an  increase  in  complexities, 
increasing  the  need  to  reduce  failures,  resulting  in  increased  costs.  The  continued  focus 
on  a  requirement-centric  at  minimum-cost  paradigm  has  endured  due  to  the  U.S.  military, 
the  “aerospace  industry’s  star  client”  according  to  Brown  and  Eremenko  (2006b,  p.  3) 

The  focus  of  military  application  of  space  systems  has  maintained  a  requirement 
based  acquisition  architecture  to  fulfill  Combatant  Commander  (COCOM)  and  national 
strategic  desires  in  the  field.  The  continuous  battle  has  been  the  cost  of  these  systems,  and 
specifically  the  best  way  to  reduce  the  lifetime  costs  while  maintaining  the  desired 
system  perfonnance.  The  draw  between  utilizing  several  smaller  satellite  constellations 
over  reduced  large,  singularly  operated  satellites  continues  to  be  examined  by  acquisition 
agencies. 

The  Defense  Advanced  Research  Projects  Agency  (DARPA)  was  issued  a 
contract  to  develop  a  project  it  termed  Future,  Fast,  Flexible,  Fractionated  Free-flying 
Spacecraft  United  by  Information  Exchange  System  (F6).  This  system  was  developed 
around  the  basis  of  fractionated  satellites  to  form  a  space-based  group  (SBG)  system 
capable  replacing  the  current  model  of  monolithic  spacecraft.  This  development  will 
change  the  concepts  of  design  and  development  of  military  satellite  systems.  The  ability 
to  relocate,  remove,  and  replace  a  single  system  in  a  cluster  is  one  of  the  many 
advantages  that  will  improve  overall  military  operations. 
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This  thesis  compares  the  architecture  of  a  SB G  to  that  of  a  system  with  a  similar 
capability  that  would  be  representative  of  a  COCOM  requirement.  It  focuses  on 
improvements  in  real-time  intelligence  and  communications;  overall  cost  of  a  system  and 
the  incorporation  of  this  architecture  into  the  current  military  satellite  construct. 

A.  BACKGROUND 

The  U.S.  military  has  exploited  the  freedom  of  space  use  for  many  decades.  The 
systems  placed  in  orbit  have  evolved  from  those  providing  basic  geolocation  to  global 
communication  to  early  warning  and  threat  assessment.  Each  system  has  been  singularly 
developed,  focused  on  meeting  national  strategic  or  COCOM  requirements.  These 
requests  for  capability  requirements  are  routed  through  several  channels  and  may  often 
result  in  an  ultimate  need  to  develop  a  new  program.  The  new  acquisition  program 
typically  utilizes  current  proven  technology  and  a  reasonable  estimate  of  maturity  of 
future  technology.  Current  acquisition  timelines  have  forced  focused  system  development 
toward  a  specific  payload  to  meet  the  requirements,  provided  by  a  primary  sensor.  As 
technology  has  advanced,  the  cost  of  implementation  of  a  single  sensor  has  increased  as 
well.  This  increased  cost  has  driven  additions  to  the  lifetime  requirements,  as  a  desire  to 
ensure  reliability  and  maintainability  of  a  system  in  order  to  fully  capture  the  cost  return. 

The  DARPA  System  F6  was  established  in  2006  as  a  program  to  develop  an 
architecture  in  which  the  functions  of  a  monolithic  system  could  be  divided  into  a  cluster 
of  wirelessly-interconnected  smaller  satellites,  sharing  resources  to  achieve  the  same 
functions  (“System  F6,”  n.d.,  para  1).  This  architecture  would  display  the  capability,  cost 
analysis,  and  viability  of  the  SBG  for  military  utilization. 

Recently,  the  System  F6  program  has  been  canceled  due  to  a  number  of  factors,  to 
include  a  lack  of  an  overall  integrator  for  the  experiment.  The  program  had  awarded 
several  small  contracts  to  companies  for  work  distribution;  however  the  lead  integrator 
role  was  not  identified  (Ferster,  2013).  This  recent  cancelation  illustrates  a  key 
performance  requirement  of  all  systems  under  development,  the  requirement  to  integrate 
all  components  for  common  use. 
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B.  PURPOSE  AND  RESEARCH  QUESTION 


The  increased  uncertainty  in  today’s  economy  has  led  to  a  minimum-cost 
acquisition  process  adopted  by  the  Department  of  Defense  (DOD).  This  process, 
combined  with  the  military  requirements-centric  paradigm,  have  led  architects  to 
conclude  that  the  answer  is  greater  capability  and  increased  system  lifetime  (Saleh, 
2006).  These  increases  have  led  to  multiple  requirements  being  placed  upon  a  system, 
increasing  costs  of  monolithic  systems. 

This  thesis  will  examine  the  benefits  of  replacing  a  monolithic  satellite  system 
with  clustered  SBG  systems,  meeting  requirements  while  reducing  subsystems  and 
complex  integration.  The  paper  will  utilize  the  FireSat  imaging  satellite  design  provided 
by  Space  Mission  Analysis  and  Design  (SMAD)  (Apgar,  Bearden,  Bell,  Berget,  Blake, 
Boden,  et  ah,  1999),  and  model  a  SBG  design,  separating  the  sensor  payload  from  the 
communications  suite.  The  analysis  will  provide  an  overall  comparison  of  space  segment 
cost  of  the  systems,  as  well  as  the  benefits  and  drawbacks  of  the  systems.  A  final  analysis 
will  expand  the  comparison  to  include  other  current  on  orbit  systems  that  could  operate  in 
conjunction  with  the  SBG.  This  comparison  will  attempt  to  answer  the  questions: 

•  Can  the  SBG  architecture  reduce  cost  of  space  systems? 

•  Could  a  SBG  allow  mission  flexibility  without  substantial  cost  increases? 

C.  BENEFITS  OF  STUDY 

Cost  reduction  is  a  highly  desired  objective  in  today’s  DOD  acquisition  process. 
Providing  equal  capabilities,  while  reducing  cost  and  improving  adaptability,  will  be  a 
focus  for  the  long  term  future  of  space  system  utilization.  This  thesis  will  examine  the 
utilization  of  SBG  architecture  within  the  DOD  Space  Systems  acquisition  program, 
detennining  the  benefits  of  this  architecture,  and  the  cost  comparison  to  that  of  current 
monolithic  architectures. 
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D. 


SCOPE  AND  METHODOLOGY 


This  thesis  will  focus  on  a  military  application  of  SBG  system  architecture.  The 
example  system,  FireSat,  architecture  utilizes  an  imaging  platform  for  forest  fire 
identification  and  monitoring.  The  cost  analysis  focuses  on  system  development,  of  the 
system,  with  the  primary  assumption  that  the  technology  utilized  was  researched  and 
developed  outside  the  architecture  of  the  system.  An  additional  assumption  is  that 
deployment  of  the  systems  will  be  accomplished  by  current  proven  means.  All  cost 
modeling  and  estimates  were  done  utilizing  Fiscal  Year  (FY)  2015  dollars,  based  on  the 
inflation  factors  chart,  table  20-1,  provided  in  SMAD  (Apgar  et  al.,  1999), 
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II.  SPACE-BASED  GROUP  COMPARISON 


A.  INTRODUCTION 

The  military  has  become  heavily  reliant  on  satellite  systems  for  daily  strategic, 
operational,  and  tactical  decisions.  The  capabilities  in  place  have  become  requirements, 
and  the  systems  providing  these  capabilities  cannot  maintain  the  growing  demand  being 
placed  on  them.  Additionally,  the  rate  at  which  technology  matures  in  today’s  economy, 
at  times,  results  in  an  obsolescent  system  prior  to  its  initial  operational  employment. 
Current  acquisition  models  typically  result  in  monolithic  architectures  to  develop  and 
deploy  new  systems  to  meet  the  growing  demand,  and  anticipate  future  demand.  The 
acquisition  architecture  utilized  by  the  DOD  requires  several  milestone  periods,  which 
could  take  years  for  transitions  between  milestones.  Figure  1  illustrates  the  acquisition 
management  the  DOD  utilizes,  and  illustrates  how  the  technological  development  of  a 
system  is  often  frozen  after  a  milestone  “B”  decision.  Future  developments  have  to 
proceed  through  the  same  process.  This  acquisition  construct  does  not  allow  for  rapid 
change  to  a  system’s  technologic  architecture  due  to  obsolescent  parts. 


lliir  Needs 


-  i  he  Material  Development  Decision  precedes  entry  into 
any  phase  of  the  acquisition  management  system 

■  Entrance  criteria  met  before  entering  phase 
•  Evolutionary  Acquisition  or  Single  Step  to  Full  Capability 


/a\  /B\  Inflation)  /c\  IOC  FOC 
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Solution 

Analysis 
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/  Development 
f  Decision 

Technology 

Development 

(’pcr''„.  (roR/i, 

Pre-EMO  /\  Post 
Review  Assess 

Engineering  and 
Manufacturing 
Development 

PDR  /">  /\  Poit-COR 
nent  *••..*  \/  Assessment 

Production  and 
Deployment 

A  F«P 

LRIPflOT&E  V 

Operations  and 
Support 

Pre-Systems  Acquisition  /\ 


7X 


Systems  Acquisition 


Sustainment 


0  = 


Decision  Point 


/\  -  Milestone  Review 


:>onj  =  Preliminary  Design  Review  (POR) 


Decision  Point  if  PDR  is  not 
conducted  before  Milestone  B 


Figure  1 .  Basic  System  Acquisition  Framework  (from  Defense  Acquisition  Portal, 

2013) 
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The  milestone  reviews  indicated  also  allow  for  program  leads  to  make  a 
detennination  to  move  toward  deployment  and  operation.  These  reviews  require  both 
technological  maturity  of  the  system  as  well  as  cost  performance  and  estimates  to  allow 
continuation  of  the  program. 

B.  MONOLITHIC  ARCHITECTURE 

The  structure  of  monolithic  satellite  system  architectures  follow  typical 
acquisition  models  utilized  by  private  and  public  businesses  alike.  This  section  outlines 
this  structure  from  concept  to  operations,  describing  some  of  the  characteristics  and 
limitations  recognized  during  a  satellite  system  development. 

1.  Concept  Inception 

A  capability  requirement  is  produced  by  national  security  strategies,  COCOMs,  or 
other  entities  responsible  for  safe  and  successful  mission  completion.  These  requests  for 
capabilities  are  what  drive  the  initial  concept  of  the  satellite  system.  The  system  concept 
is  refined  through  multiple  requirement  characterizations,  with  a  final  perfonnance 
requirement  being  defined  prior  to  milestone  “A”.  Once  the  final  perfonnance 
requirement  is  set,  an  associated  payload  sensor  that  can  accomplish  the  mission  set 
would  be  researched  and  chosen.  The  associated  payload  is  scrutinized  to  determine  the 
required  subsystems  needed  to  fulfil  the  payload  requirements,  and  an  estimated  lifetime 
cost  is  created.  The  cost  of  these  systems  have  often  increased  steadily  over  time,  leading 
architects  and  managers  to  come  to  an  inaccurate  conclusion  that  greater  capability  is 
required  to  offset  the  cost  growth  (Brown  &  Eremenko,  2006b).  This  results  in  additional 
payload  requirements  and  complexities  when  moving  forward  into  the  design  and 
development  of  the  system. 

2.  Design  and  Development 

When  the  primary  payload  has  been  defined,  the  design  and  development  of  the 
monolithic  system  begins.  The  design  phase  of  a  space  borne  system  is  a  major  focus  of 


6 


program  management,  in  that  the  desire  is  to  provide  the  best  subcomponents  for  the 
system,  while  still  maintaining  a  low  cost  and  on  time  delivery.  Achieving  a  reliable,  cost 
effective  system  becomes  the  focus  of  managers,  while  still  remaining  under  the 
pressures  of  program  and  technical  uncertainty.  These  goals  often  lead  to  a  complex 
spacecraft  with  multi-mission  set  requirements,  driving  costs  higher  and  higher.  The 
responses  to  cost  increases  have  been  to  maximize  the  capability  versus  cost  quotient  by 
increasing  the  spacecraft  scale  and  increasing  the  system  lifetime  (Saleh  2008).  This 
response  is  does  not  always  allow  for  appreciated  cost  savings. 

a.  Multi-mission  Design 

The  ability  to  fuse  a  system  to  provide  a  range  of  payloads  to  satisfy  several  user 
requirements  is  an  approach  that  a  program  management  can  utilize.  This  multi-mission 
capability  allows  for  a  more  secure  program  during  development.  However,  there  are 
several  limitations  to  a  multi-mission  design,  and  these  limitations  can  increase  as  the 
program  matures.  First,  a  mission  requirement  change  in  a  single  portion  of  the  system 
during  development  may  require  a  larger  system  design  change.  This  design  change,  in 
turn,  results  in  increased  cost  and  delayed  scheduling,  and  can  jeopardize  the  program.  A 
second  risk  to  a  multi-mission  program  is  the  requirements  of  each  payload  or  subsystem, 
and  negative  interactions  between  them  (Owen  &  Eremenko,  2006a). 

Orndorff  and  Zink  (2010)  illustrated  this  complexity  in  an  example  of  a 
payload  that  requires  precision  pointing  and  low  jitter,  but  produces  a 
large  amount  of  valuable  data.  Getting  the  data  to  the  ground  requires  high 
power,  which  drives  the  solar  arrays  to  grow,  which  in  turn  disturbs  the 
pointing  and  jitter  control  capability  of  the  space  vehicle,  (p.  275) 

For  a  multi-mission  system,  independent  development  of  smaller  satellites  may 
provide  better  cost  and  risk  reduction  to  a  program,  as  compared  to  the  current  paradigm 
used  in  typical  architectures. 
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b.  Technological  Limitations 


A  satellite  system  requires  tested  technology  for  employment  into  the  space 
environment.  The  DOD  and  National  Aeronautics  and  Space  Administration  (NASA) 
utilize  Technology  Readiness  Levels  (TRLs)  to  systematically  measure  system  and 
subsystem  maturity  for  utilization.  The  TRLs  range  from  one  to  nine,  from  least  to  most 
mature  systems  respectively.  The  example  of  NASA’s  TRLs  is  illustrated  in  Table  1. 

These  TRLs  have  huge  impacts  on  the  design  and  development  life  of  a  space 
borne  system.  During  design,  the  payload  and  subsystems  are  set  based  on  current  mature 
technology,  or  technology  that  is  expected  to  reach  maturity  prior  to  employment  of  the 
system.  These  restrictions  require  utilization  of  proven,  less  advanced  technology  for 
each  sensor  and  subsystem  in  a  monolithic  satellite.  In  addition,  there  comes  a  point 
during  the  acquisition  phase  in  which  a  technology  freeze  must  be  implemented.  This 
forces  the  development  of  the  current  system  with  no  additional  changes  or  upgrades  to 
the  technology  placed  within  the  satellite.  This  requirement  ensures  the  program  stays  on 
schedule  and  reduces  programmatic  cost  that  would  result  from  integration  and  testing  of 
newly  developed  technology.  Fixing  the  design  restricts  the  overall  future  capability  of 
the  system  in  development,  freezing  the  system  maturity  to  a  point  in  time  prior  to  the 
system  employment.  In  order  for  a  capability  to  be  achieved  utilizing  advanced 
technology,  a  new  system  must  be  developed.  The  result  is  a  program  which  continuously 
requires  redevelopments  to  employ  newer  capabilities  to  replace  the  current  system,  or 
acquiescing  on  a  less  advanced  technological  system  to  be  utilized  for  the  original 
lifetime  of  the  system.  The  later  response  is  often  chosen  due  to  cost  constraints  and 
project  uncertainties. 
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Table  1.  NASA  Technology  Readiness  Level  Chart  (from  Mankins,  1995) 


Technology 
Readiness  Level 

Description 

1 .  Basic  principles 
observed  and 
reported 

This  is  the  lowest  “level”  of  technology  maturation.  At  this 
level,  scientific  research  begins  to  be  translated  into  applied 
research  and  development. 

2.  Technology 
concept  and/or 
application 
formulated 

Once  basic  physical  principles  are  observed,  then  at  the  next 
level  of  maturation,  practical  applications  of  those 
characteristics  can  be  ‘invented’  or  identified.  At  this  level, 
the  application  is  still  speculative:  there  is  not  experimental 
proof  or  detailed  analysis  to  support  the  conjecture. 

3.  Analytical  and 
experimental  critical 
function  and/or 
characteristic  proof 
of  concept 

At  this  step  in  the  maturation  process,  active  research  and 
development  (R&D)  is  initiated.  This  must  include  both 
analytical  studies  to  set  the  technology  into  an  appropriate 
context  and  laboratory-based  studies  to  physically  validate 
that  the  analytical  predictions  are  correct.  These  studies  and 
experiments  should  constitute  “proof-of-concept”  validation 
of  the  applications/concepts  formulated  at  TRL  2. 

4.  Component  and/or 
breadboard 
validation  in 
laboratory 
environment 

Following  successful  “proof-of-concept”  work,  basic 
technological  elements  must  be  integrated  to  establish  that 
the  “pieces”  will  work  together  to  achieve  concept-enabling 
levels  of  performance  for  a  component  and/or  breadboard. 

This  validation  must  be  devised  to  support  the  concept  that 
was  formulated  earlier,  and  should  also  be  consistent  with  the 
requirements  of  potential  system  applications.  The  validation 
is  “low-fidelity”  compared  to  the  eventual  system:  it  could  be 
composed  of  ad  hoc  discrete  components  in  a  laboratory. 

5.  Component  and/or 
breadboard 
validation  in 
relevant 
environment 

At  this  level,  the  fidelity  of  the  component  and/or  breadboard 
being  tested  has  to  increase  significantly.  The  basic 
technological  elements  must  be  integrated  with  reasonably 
realistic  supporting  elements  so  that  the  total  applications 
(component-level,  sub-system  level  or  system-level)  can  be 
tested  in  a  “simulated”  or  somewhat  realistic  environment. 

6.  System/subsystem 
model  or  prototype 
demonstration  in  a 
relevant 

environment  (ground 
or  space) 

A  major  step  in  the  level  of  fidelity  of  the  technology 
demonstration  follows  the  completion  of  TRL  5.  At  TRL  6,  a 
representative  model  or  prototype  system  or  system  -  which 
would  go  well  beyond  ad  hoc,  “patch-cord”  or  discrete 
component  level  breadboarding — would  be  tested  in  a 
relevant  environment.  At  this  level,  if  the  only  “relevant 
environment”  is  the  environment  of  space,  and  then  the 
model/prototype  must  be  demonstrated  in  space. 
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Technology 
Readiness  Level 

Description 

7.  System  prototype 
demonstration  in  a 
space  environment 

TRL  7  is  a  significant  step  beyond  TRL  6,  requiring  an  actual 
system  prototype  demonstration  in  a  space  environment.  The 
prototype  should  be  near  or  at  the  scale  of  the  planned 
operational  system  and  the  demonstration  must  take  place  in 
space. 

8.  Actual  system 
completed  and 
“flight  qualified” 
through  test  and 
demonstration 
(ground  or  space) 

In  almost  all  cases,  this  level  is  the  end  of  true  “system 
development”  for  most  technology  elements.  This  might 
include  integration  of  new  technology  into  an  existing 
system. 

9.  Actual  system 
“flight  proven” 
through  successful 
mission  operations 

In  almost  all  cases,  the  end  of  last  “bug  fixing”  aspects  of 
true  “system  development.”  This  might  include  integration  of 
new  technology  into  an  existing  system.  This  TRL  does  not 
include  planned  product  improvement  of  ongoing  or  reusable 
systems. 

c.  Reliability  Development 

Once  a  system  has  been  designed  and  development  is  underway,  a  focused  desire 
is  to  incorporate  reliability  and  fragility  for  reduced  mission  degradation  or  failures  as  a 
result  of  any  system  damage.  Fragility,  as  defined  by  Brown  and  Eremenko  (2006a)  “is 
the  tendency  of  complex  systems  to  exhibit  unmodeled  failure  modes,  usually  due  to  an 
unanticipated  component  interaction  leading  to  a  catastrophic,  albeit  improbable, 
sequence  of  events”  (p.  2).  Reliability  is  the  tendency  of  the  system  to  be  trusted  to 
perform  as  designed,  and  to  provide  the  data  as  required  by  the  customer.  The 
developmental  requirements  to  attain  reliability  and  flexibility  necessitate  continued 
examination  of  essential  parts  of  the  system  during  development.  Every  subsystem 
required  to  provide  support  to  the  payload  must  be  scrutinized,  ensuring  that  margins  or 
additional  redundant  components  are  incorporated  in  order  to  provide  a  reliable  system 
(Brown  &  Eremenko,  2006a). 
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The  additions  to  a  system  to  ensure  reliability  are  not  enough  to  protect  against 
failure  of  employment  and  operation  of  the  spacecraft.  Several  factors  can  occur  that 
would  result  in  a  loss  in  the  capability  that  the  system  is  due  to  provide,  such  as  launch 
vehicle  failure,  damage  during  launch,  in-space  collision,  etc.  These  additional  failures 
require  contingencies  in  order  to  ensure  capabilities  are  not  lost.  Commercial  companies 
require  additional  insurance  to  cover  these  costs,  such  as  10  percent  to  20  percent  of  the 
payload  replacement  cost  for  launch  failure,  and  an  annual  two  percent  to  five  percent  on- 
orbit  insurance  (“Commercial  space,”  2002).  For  the  DOD,  the  missions  often  require  an 
expensive  replacement  in  the  event  of  a  failure  during  employment,  even  though  they  are 
technically  self-insured  (Brown  &  Eremenko,  2006b). 

3.  Test  and  Employment 

Once  a  system  has  completed  milestone  B,  it  proceeds  to  test  and  evaluation, 
while  continued  development  of  the  system  is  completed.  The  parallel  test  and 
development  allows  for  contractors  to  improve  systems  prior  to  full  implementation  and 
integration. 


a.  Payload  Integration 

Great  design  and  detail  are  required  for  payload  integration  of  a  monolithic 
satellite  system.  A  singular  satellite  must  ensure  common  communication  between  the 
payload,  the  power  subsystems,  the  data  storage  devices,  and  the  communication  suite. 
This  focused  integration  within  a  single  system  results  in  a  single  contractor,  responsible 
for  the  development  of  all  the  systems,  ensuring  proper  integration.  Combine  this  with  a 
multiple  mission  system,  and  the  coupled  interfaces  increase  the  development  risk,  which 
in  turn  requires  combinatorial  complexity  during  testing  (Omdorff  &  Zink,  2010). 
Integration  is  a  discipline  that  requires  complex  interaction  between  the  monolithic 
system  itself,  as  well  as  the  ground  segments  which  receive  from  and  transmit  to  the 
system. 


11 


b.  Demand  Requirements 


During  payload  integration  and  system  development,  the  required  perfonnance 
demand  for  a  system  must  be  determined.  This  detennination  must  be  made  for  a  future 
date,  due  to  increases  in  development,  manufacturing,  and  launch  windows  (Brown  & 
Eremenko,  2006a).  The  system  must  be  able  to  meet  these  demands,  which  often  involve 
the  quality,  availability,  and  repeatability  of  the  products  provided.  Added  into  this 
demand  is  an  estimated  increase  in  customers  once  operational.  An  ideal  example  of 
added  customers  is  that  of  military  satellite  communications  (SATCOM).  Developed 
initially  for  naval  vessels  at  sea,  the  requirement  has  spread  to  all  military  units;  at  sea, 
ashore,  desert,  or  jungle.  The  result  has  been  the  development  of  the  Mobile  User 
Objective  System  (MUOS)  to  replace  the  current  UHF  follow-on  SATCOM  system.  The 
MUOS  will  increase  SATCOM  accessibility  in  theater  (Bandil,  Pandya,  &  Shields, 
2010). 

A  monolithic  system  cost  can  increase  exponentially  when  attempting  to  meet  all 
of  the  requirements  that  would  expanded  its  capability.  Frequently,  trade-offs  must  occur 
to  reach  cost  goals  while  sacrificing  requirements.  For  example,  program  developers  will 
trade  the  amount  of  data  a  payload  can  provide  with  the  bandwidth  used  to  transmit  that 
data  down  to  a  ground  station  (Omdorff  &  Zink,  2010).  This  type  of  trade-off  results  in  a 
system  that  does  not  fully  meet  the  intent  of  the  request  for  capability;  and  is  an  inherent 
problem  with  a  single,  monolithic  system. 

c.  On-Orbit  Operations 

Once  a  monolithic  system  is  placed  into  orbit,  the  product  provided  is  highly 
scrutinized  by  the  customer  that  receives  it.  Once  fully  operational,  the  quality  of  data 
provided  will  also  affect  the  demand  placed  on  the  system,  and  the  combined  result  of  the 
system  to  meet  the  demand  and  the  product  will  feed  into  the  cost  allotted  for  maintaining 
and  operating  the  system.  This  cost  could  result  in  continued  operation  past  the  initial 
date,  or  could  cause  the  DOD  to  remove  funding  and  kill  the  project  before  the  intended 
lifetime  has  been  reached.  The  volatility  of  military  funding  and  national  economics 
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require  a  quick  and  accurate  assessment  of  a  system’s  vitality  to  the  overall  mission  it  has 
been  developed  to  support.  The  operation  and  maintenance  of  a  space  system,  conversely 
to  that  of  other  DOD  acquisition  programs,  covers  only  30  percent  of  the  total  lifetime 
cost  of  the  program,  as  displayed  in  Figure  2.  If  a  monolithic  satellite  has  been  placed  that 
will  not  meet  the  requirements  set  forth  during  development,  the  system  will  be  discarded 
and  a  new  development  process  will  begin,  resulting  in  an  exuberant  cost  increase  to  the 
program. 


Figure  2.  DOD  versus  Space  Life  Cycle  Cost  Curve  (from  Department  of  Defense 

Space  Acquisition,  2014) 

When  a  monolithic  system  provides  quality  information,  the  forced  demand  on 
that  system  will  increase.  This  will  often  lead  to  delayed  products  and  inaccurate 
assessments  of  poor  performance  by  the  customers.  A  monolithic  system  can  only 
provide  to  the  expectations  of  demand  that  were  designed  into  the  system  years  prior  to 
employment.  With  the  advancement  of  technology,  these  capabilities  are  often  times 
enormously  low  as  compared  to  the  mid-life  demands  placed  on  the  system.  The  only 
response  the  DOD  has  to  correct  for  increase  demand  is  to  supplement  the  current 
systems  with  additional  support  prior  to  scheduled  replacement  with  more  advanced 
systems.  An  example  of  this  addition  was  adding  UHF  Follow-On  (UFO)  satellite  FI  1,  as 
a  gap  filler  between  the  UFO  communications  system  and  MUOS,  which  is  a  next 
generation  narrowband  communication  system  (Ghyzel,  2010). 
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c. 


UTILIZATION  OF  SPACE  BASED  GROUPS 


The  SBG  architecture  grants  several  cost  advantages  to  the  current  monolithic 
architecture  utilized  today.  The  flexibility  to  contract  out  pieces  of  a  system  during  design 
and  development  can  provide  cost  savings  to  the  DOD,  due  to  competitive  pricing  on 
individual  items,  vice  a  single  satellite.  Once  deployed,  SBG  systems  will  reduce 
operation  cost,  increase  the  reliability  and  maintainability  of  the  system,  and  provide 
quick  and  relatively  cheaper  replacement  options  for  customers  and  contractors  alike.  The 
savings  is  focused  on  how  many  satellites  can  perform  dissimilar  functions  within  the 
system  (Brown  &  Eremenko,  2006a).  Working  from  this  concept,  system  design  and 
development  can  proceed,  with  the  payloads  of  each  system  proceeding  parallel  to  the 
others. 


1.  Development 

The  development  of  a  SBG  system  can  save  schedule  cost,  contractor  cost,  and 
allow  for  future  expansion  of  the  system.  The  ability  to  award  contracts  for  individual 
modules,  developed  somewhat  independently  of  each  other,  allows  for  competition  and 
cost  reduction.  Each  contractor  can  develop,  in  parallel,  a  smaller  system  that  will  meet 
the  requirements  provided,  and  the  subsystems  required  to  support  that  payload. 
Additionally,  since  the  systems  are  independent,  they  do  not  need  to  be  functionally 
identical  (Orndorff  &  Zink,  2010).  The  additional  integration  with  the  communication 
hub  satellite  is  the  only  common  portion  needing  development.  This  requirement  is  the 
foundation  of  what  binds  the  acquisition  schedule  of  the  system.  While  delays  in  the 
communications  satellite  could  result  in  schedule  slippage,  the  fractionated  architecture 
of  other  components  could  allow  for  a  steady  schedule  despite  minor  delays,  allowing 
required  milestones  to  be  met  on  time. 

As  stated  previously,  the  uncertainty  during  development  can  often  lead  to 
unanticipated  expenses  and  schedule  slippage.  When  the  SBG  architecture  is  used  for 
development,  additional  options  are  provided  that  allow  for  subsequent  modifications  in 
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the  event  of  unanticipated  changes.  These  options  provide  real  value  that  can  be 
computed  into  the  architecture  itself  (De  Week  et  ah,  2004). 

2.  Overall  Integration 

Integration  is  the  key  to  any  system  under  development  in  today’s  military. 
Integration  between  systems  in  a  platform,  as  well  as  integration  between  platfonns  has 
become  a  continued  focus  within  military  leadership. 

Vice  Adm.  Dunaway,  the  Naval  Aviation  (NAVAIR)  Commander  (2013), 
has  stated  that  NAVAIR  is  committed  to  develop  the  processes,  skills,  and 
tools  to  successfully  execute  mission-level  systems-of-systems 
engineering,  test  and  evaluation,  and  logistics — ensuring  all  of  these 
important  elements  are  as  tightly  integrated  as  the  capabilities  we  deliver 
to  the  Fleet,  (p.  4) 

With  a  SBG  structure,  the  development  and  fabrication  of  each  module  could  be 
divided  among  multiple  contractors,  but  this  requires  a  standardized  inter-module 
interface  (Brown,  2004).  The  DARPA  F6  project  was  cancelled  by  Brad  Tousley  for 
several  reasons,  including  no  overall  integrator  for  the  experiment  (Ferster,  2013).  The 
integration  of  any  system  is  the  key  element  to  the  program  success,  and  for  SBG,  a 
central  communication  hub  satellite  that  provides  the  routing  and  control  services  is 
required  to  meet  this  integration  necessity  (Orndorff  &  Zink,  2010). 

The  SBG  architecture  focuses  on  utilizing  the  communication  hub  satellite  with 
additional  smaller  satellites  that  provide  the  required  capability  each  was  designed  for  to 
the  desired  customers.  The  entire  cluster  of  satellites  would  utilize  a  wireless  Internet 
Protocol  local  area  network  (LAN)  to  relay  information  throughout  the  group. 
Experiments  utilizing  wireless  networks  have  been  used  to  confirm  the  capability 
onboard  the  Mir  and  International  Space  Station  (Orndorff  &  Zink,  2010).  The  success  of 
these  experiments,  in  both  ensuring  data  exchange,  even  at  low  transmitter  power,  shows 
that  utilization  of  wireless  networks  in  space  is  feasible  (Lofton,  &  Conley,  1997).  The 
wireless  network  will  allow  for  each  system  to  provide  the  required  data  to  the  hub 
satellite.  This  data  exchange  needs  to  be  robust  while  allowing  for  a  resistance  to 
interferences  that  are  expected  to  be  experienced  (Sahel,  2006).  Each  satellite’s  data  must 
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also  be  capable  of  data  transmission  through  the  communication  satellite  to  a  ground 
station,  or  stored  in  a  data  storage  device  onboard  the  hub  satellite. 

Data  storage  and  transmission  is  the  major  integration  problem  in  a  SBG  design. 
The  hub  satellite  must  be  capable  of  receiving,  and  possibly  converting,  payload  data 
required  by  the  customers.  This  data  must  also  be  capable  of  being  compressed,  and 
transmitted  concurrently  with  other  data  from  other  mission  satellites.  The  integration 
should  be  granted  to  the  hub  satellite  contract,  ensuring  that  the  central  network  satellite 
can  perform  the  mission  of  integrating  all  the  data  into  a  usable  and  transmittable  fonn. 

3.  On-Orbit  Maintainability 

A  separate  issue  that  can  arise  for  any  system  in  orbit  is  the  requirement  to  fix  or 
replace  the  system  due  to  mechanical  malfunction  or  damage  due  to  launch  or  space- 
borne  hazards.  The  standard  procedure  for  a  malfunctioning  system  is  to  either  utilize  it 
under  degraded  conditions  or  decommission  it  and  employ  a  replacement.  A  small 
fraction  of  satellite  that  have  malfunctioned  have  been  repaired,  however  that  avenue  is 
expensive,  limited  to  low  earth  orbit  systems,  and  unfeasible  in  today’s  environment 
without  a  manned  space  vehicle  capable  of  providing  that  type  of  access  for  mechanical 
work. 

A  SBG  system,  by  virtue  of  each  component  of  the  system  being  fractionated, 
allow  for  flexibility  in  the  event  of  different  uncertainties,  such  as  technical  failures  and 
component  obsolescence  (De  Week,  De  Nuefville,  &  Chaize  2004).  A  malfunctioning 
component  can  be  replaced  at  cost  of  the  single  component  plus  launch.  This  can  also  be 
completed  for  system  components  that  have  become  obsolete,  or  for  a  technology  that  has 
been  matured  that  would  dramatically  improve  the  perfonnance  of  the  SBG  system.  The 
entire  system  would  not  need  to  be  replaced  for  improvements;  additional  components 
need  only  join  the  network  for  the  enhancements  to  be  realized. 

Additionally,  a  SBG  system  could  be  designed  with  an  on-orbit  servicing 
component,  a  satellite  capable  of  perfonning  minor  repairs  required  during  the  lifetime  of 
the  system.  These  servicing  satellites  would  be  employed  in  large  SBG  clusters  where 
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quick  replacement  would  not  be  feasible,  such  as  in  geosynchronous  orbit;  or  a  situation 
where  failure  of  a  major  component  could  not  be  tolerated,  such  as  the  communications 
satellite  of  a  high  demand  system.  Omdorff  and  Zink  state  “fully  autonomous  servicing 
has  been  proven  on  orbit  with  the  DARPA  Orbital  Express  mission.  Orbital  Express 
successfully  demonstrated  autonomous  rendezvous,  cooperative  and  uncooperative 
docking,  fuel  transfer,  and  replacement  of  individual  packaged  components”  (2010,  p. 
277).  The  design  would  need  to  be  defined  as  an  initial  capability  during  development, 
but  could  be  built  to  reduce  overall  lifetime  cost. 

D.  CHAPTER  SUMMARY 

This  previous  chapter  has  developed  an  architecture  comparison  of  the  current 
monolithic  systems  and  that  of  a  SBG  fractionated  system.  The  current  paradigm  that  the 
military  utilizes  to  fulfil  requirements  is  flawed  and  has  resulted  in  requiring  greater 
capabilities  on  a  system  in  order  to  answer  cost  growth,  which  has  had  the  effect  of 
increasing  those  costs  (Brown  &  Eremenko  2006b).  The  desire  is  to  provide  a 
replacement  for  these  traditional,  large  monolithic  satellites  with  a  SBG  of  satellites, 
which  would  fly  in  a  wirelessly  linked  network  (Orndorff  &  Zink,  2010).  This 
architecture  would  allow  for  parallel  development  of  components,  transition  to 
integration  of  a  system-of-systems,  and  a  capability  to  repair  or  replace  a  component 
faster  than  current  technologies  allow. 
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III.  RESEARCH  ANALYSIS 


A.  INTRODUCTION 

This  chapter  will  utilize  the  FireSat  example  architecture  found  in  SMAD  and  a 
fractionated  breakdown  of  the  sensor  will  be  analyzed  for  cost  comparison.  FireSat’s 
architecture  was  defined  by  the  requirement  for  an  imaging  platform  to  conduct  forest 
fire  detection  and  monitoring.  This  chapter  will  present  these  requirements  and  the 
process  in  which  a  suitable  payload  system  was  developed.  The  chapter  will  also  examine 
the  comparison  between  the  communication  requirements  of  FireSat  and  those  required 
of  a  SBG,  with  the  expectation  of  growth  of  the  requirements  of  the  constellation. 

B.  MISSION  REQUIREMENTS 

The  first  emphasis  of  any  system  is  to  define  the  overarching  program  objectives. 
The  objectives  are  the  strategic  mission  goals  that  the  customer  provides  to  the 
government,  contractor,  or  other  developmental  units.  With  the  environment  of  today, 
primary  objectives  and  secondary  objectives  are  often  times  developed  to  allow  for  multi¬ 
purpose  or  multi-functional  systems.  The  FireSat  program  was  given  the  following 
objectives,  found  in  figure  1-4  in  SMAD  (from  Apgar  et  al.,  1999,  p.  13).  The  primary 
objective  was  “to  detect,  identify,  and  monitor  forest  fires  throughout  the  United  States, 
including  Alaska  and  Hawaii,  in  near  real  time”  (from  Apgar  et  al.,  1999,  p.  13) 
Additional  secondary  objectives  were: 

•  To  demonstrate  to  the  public  that  positive  action  is  underway  to  contain 
forest  fires. 

•  To  collect  statistical  data  on  the  outbreak  and  growth  of  forest  fires. 

•  To  monitor  forest  fires  for  other  countries. 

•  To  collect  other  forest  management  data. 

These  objectives  allowed  for  focused  allotment  of  resources  by  the  developmental 
teams,  while  still  allowing  free  design  to  accomplish  the  desired  goal.  The  objectives  of  a 
program  are  translated  into  high  level  mission  requirements,  which  drive  the  specific 
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architecture  development  for  a  system.  The  requirements  provide  specific,  measurable 
performance  specifications  that  the  system  is  required  to  meet.  Table  2  provides  the  top- 
level  requirements  that  are  derived  for  FireSat. 

The  FireSat  requirements  drive  several  aspects  of  the  system,  including  orbit, 
sensor,  and  selection,  payload  operation  and  support,  and  launch.  The  following  sections 
break  apart  these  sections,  as  provided  by  SMAD,  to  fractionated  type  architecture.  A 
focus  of  the  research  is  based  on  the  idea  that  each  SBG  satellite  focuses  on  a  single 
mission  element,  therefore  simplifying  engineering  and  integration  efforts  (Orndorff  & 
Zink,  2010). 


Table  2.  FireSat  Top-Level  Mission  Requirements  (from  Apgar  et  ah,  1999,  p.  16) 


Requirements 

Functional 

Performance 

4  temperature  levels 

30  m  resolution 

500  m  location  accuracy 

Coverage 

Daily  coverage  of  750  million  acres  within 
Continental  United  States  (CONUS) 

Responsiveness 

Send  registered  mission  data  within  30  min  to 
up  to  50  users 

Secondary  Mission 

4  temperature  levels  for  pest  management 

Operational 

Duration 

Mission  operational  at  least  10  years 

Availability 

98  percent  excluding  weather 

3 -day  maximum  outage 

Survivability 

Natural  environment  only 

Data  Distribution 

Up  to  500  fire -monitoring  offices 
+2,000  rangers  worldwide  (maximum  of  100 
simultaneous  users) 

Data  Content,  Form,  &  Format 

Location  and  extent  of  fire  on  any  of  12  map 
bases,  average  temperature  for  each  30  nr  grid 
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Requirements 

Constraints 

Cost 

Less  than  $20M/year  plus  research  and 
development 

Schedule 

Initial  operating  capability  within  5  years, 
final  operating  capability  within  6  years 

Regulations 

NASA  mission 

Political 

Responsive  to  public  demand  for  action 

Environment 

Natural 

Interfaces 

Communication  relay  and  interoperable 
through  NOAA  ground  stations 

Developmental 

Launch  on  Space  Transportation  System 
(STS)  or  expendable 

No  unique  operations  people  at  data 
distribution  nodes 

C.  FRACTIONAL  DIVISION 

A  fractional  system  provides  the  ability  to  diversify  the  system  between  different 
components  and  functions.  The  following  paragraphs  detail  the  breakdown  of  FireSat,  as 
a  monolithic  system,  to  a  SBG  of  a  single  optical  sensor  system. 

1.  Orbital  Modeling 

The  initial  mission  element  required  to  develop  an  effective  space  system  is  to 
detennine  where  in  space  it  will  be  designed  to  operate.  The  orbital  modeling  drives  the 
payload  and  subsystem  capabilities  to  achieve  the  mission.  Selection  of  an  orbit  is  often  a 
compromise  of  the  ability  to  perform  to  perfect  specifications,  and  the  least  costs  options 
of  a  specific  payload  desired.  During  analysis  of  alternatives,  a  specific  payload 
capability  may  restrict  the  orbital  parameters  in  which  the  system  can  operate. 
Additionally,  subsystem  capabilities  or  launch  limitations  will  dictate  some  of  the  orbital 
parameters.  This  analysis  must  be  done  early  and  often  during  acquisition  of  a  system,  as 
slight  details  could  impact  the  system’s  capability  to  meet  the  requirements  due  to  orbital 
placement.  The  orbit  design  required  focuses  on  meeting  the  objectives  of  the  FireSat 
program,  specifically  revisit  time  of  a  specific  area  for  surveillance  or  communications. 
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The  objective  of  FireSat  was  to  be  able  to  detect,  identify,  and  monitor  forest  fires 
in  real  time;  as  well  as  provide  some  additional  tasks,  to  include  public  reassurance  of 
current  forest  fire  contaimnent.  This  drives  a  requirement  of  daily  coverage  within 
CONUS,  with  no  more  than  three  days  of  outage  for  availability,  with  an  objective  of 
including  Hawaii,  Alaska,  and  other  regions.  The  ideal  orbital  position  to  provide  real¬ 
time,  continuous  coverage  would  be  a  geostationary  earth  orbit  (GEO).  This  would  allow 
for  100  percent  coverage  of  the  continental  United  States,  but  would  not  allow  a  single 
satellite  to  provide  coverage  of  Alaska  and  Hawaii.  The  cost  increase  for  a  payload  and 
subsystem  capable  of  providing  the  data  also  increases,  as  well  as  requirements  in 
reaching  GEO.  Recent  accounts  of  government  acquisition  programs  utilizing 
conventional  GEO  systems  have  had  negative  results  on  cost,  schedule,  and  perfonnance 
(Orndorff  &  Zink,  2010). 

Utilizing  the  requirements  provided,  the  ideal  orbit  to  satisfy  the  program  needs 
was  a  circular  orbit  near  700  km  with  an  inclination  that  provides  the  access  times  to 
CONUS.  The  design  point  utilizes  an  inclination  of  55  deg  at  this  altitude,  and  to  utilize 
two  systems  with  a  Right  Ascension  of  the  Ascending  Node  (RAAN)  offset  of  120  deg 
(Apgar  et  al.,  1999).  The  cost  analysis  completed  only  focused  on  a  single  system  at 
RAAN  of  0  deg,  using  the  assumption  the  additional  system  offset  provides  the  capability 
to  fill  the  multi-hour  gaps  observed.  The  program  System  Tool  Kit  (STK)  was  utilized  to 
develop  an  orbital  model  and  to  compute  access  periods  for  the  imaging  sensor  and 
communication  points.  The  desired  communication  ground  stations  utilized  were  the 
National  Oceanic  and  Atmospheric  Administration  (NOAA)  stations  located  in  Alaska 
and  Maryland.  The  inputs  for  orbital  information,  area  of  interest,  ground  stations, 
sensors,  and  communication  systems  are  provided  in  Table  2.  Figure  3  provides  a  2D 
view  of  the  area  of  interest,  the  FireSat  ground  trace  for  a  single  orbit,  and  the  ground 
station  locations  that  were  be  utilized.  Access  times  to  the  area  of  interest  and  ground 
stations  are  illustrated  in  Figure  4  and  Figure  5,  respectively.  The  assumption  was  made 
that  a  FireSat  SBG  has  an  identical  orbits  and  imaging  sensor.  As  displayed  in  Figure  5,  a 
single  sensor  would  have  daily  access  to  either  ground  station. 
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Figure  3.  FireSat  2D  Model  from  STK  v.  10 


- 1 - 1 — 

Sat  8  Sat  1 5 

Figure  4.  FireSat  Observation  of  Wildfire  Area  from  STK  v.  10 
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NOAA  GS  MD-  Times 


-NOAA  GS  AK- Times 


Figure  5.  FireSat  Communication  Access  to  NOAA  Ground  Stations  from 

STKv.  10 


2.  Sensor  Selection 

An  observation  and  alert  platfonn,  such  as  FireSat,  requires  an  optical  sensor 
capable  of  not  only  monitoring  large  area  fires,  but  detection  of  small  fires  to  allow  for 
early  response  for  prevention  of  large  area  damage.  This  optic  requires  high  fidelity  to 
perform  this  detection,  and  an  ability  to  perform  day  or  night  detection.  This  initial 
requirement  leads  to  utilization  of  a  passive  Infrared  optic. 

To  develop  a  preliminary  understanding  of  the  optic,  it  is  required  to  step  through 
design  process,  as  provided  in  SMAD  pages  293  through  297.  Table  3  outlines  the 
calculated  results  based  on  the  requirements  of  30  m  resolution  and  selection  of  a 
700  km,  circular  orbit. 
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Table  3.  Sensor  Design  Parameters  (from  Apgar  et  al.,  1999,  pp.  293-297) 


Parameter 

Value 

Orbital  Altitude 

700 

km 

Orbit  Period 

98.8 

min 

Ground  Track  Velocity 

6.76 

km/s 

Node  Shift 

24.8 

deg 

Earth  angular  radius 

64.3 

deg 

Max.  Horizontal  Distance 

3069 

km 

Max.  Incidence  Angle 

70 

deg 

Nadir  Angle 

57.9 

deg 

Min.  Elevation  Angle 

20 

deg 

Earth  Central  Angle 

12.1 

deg 

Slant  Range 

1578 

km 

Swath  Width 

24.2 

deg 

Max.  Ground  Sampling  Distance  along  track 

68 

m 

Instantaneous  field  of  view 

0.00245 

deg 

Max  cross-track  pixel  resolution  at  ECArnax 

199.6 

m 

Cross-track  ground  pixel  resolution  at  nadir 

90 

m 

Along-track  pixel  resolution  and  nadir 

90 

m 

Number  of  cross-track  pixels 

4.70E+04 

Number  of  swaths  recorded  along-track  in  1 

second 

225.6 

Number  of  pixels  recorded  in  1  second 

1.06E+07 

Number  of  bits  used  for  each  pixel 

8 

bits 

Data  rate 

85 

Mbps 

Number  of  pixels  for  whiskbroom  Inst. 

256 

Pixel  integration  period 

24.1 

ps 

Pixel  read-out  frequency 

42 

kHz 
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This  information  is  the  basic  starting  block  for  the  design  of  the  system.  This 
information  feeds  the  requirements  of  the  sensor  and  communications  suite.  SMAD  also 
provides  a  typical  payload  characteristics  table  that  can  allow  for  desired  payload 
estimates,  and  is  found  on  page  275  (Apgar  et  ah,  1999).  For  the  given  FireSat 
requirements,  a  Multi-spectral  Mid-IR  optic  was  used  to  compare  to  the  requirements  of 
the  sensors,  with  adjustments  to  the  sensor  characteristics  based  on  aperture  ratio  of  0.26. 
This  resulted  in  the  following  payload  size: 

•  size:  0.4  m  x  0.3  m  diameter 

•  mass:  28  kg 

•  average  power  at  28  V:  32  watts 

The  mass  and  power  results  were  based  on  an  increased  factor  of  2,  due  to  the 
substantial  reduction  in  the  payload  size  (Apgar  et  al.,  1999,  p.  297). 

3.  Operation  and  Support 

As  discussed  in  an  earlier  chapter,  the  operation  and  support  cost  of  a  satellite 
system  is  approximately  30  percent  of  the  total  lifetime  cost  of  the  system.  The  following 
sections  express  the  how  a  SBG  system  can  reduce  risk  and  cost  for  initial  operation  and 
expresses  the  benefits  a  sensor  only  platform  provided  to  everyday  operations. 
Reparability  of  a  SBG  is  also  explored;  however  current  cost  and  risk  comparison  are  not 
within  the  scope  of  this  research. 

a.  Initial  Operation  Capability 

Often  times  the  initial  operational  capability  depends  upon  the  current 
technological  maturity  of  the  subsystems  being  incorporated  into  the  satellite  and  ground 
support  stations,  as  discussed  in  an  earlier  chapter.  The  FireSat  example  shows  two 
specific  areas  that  require  modifications  in  order  to  obtain  the  best  result  with  the  lowest 
cost.  These  areas  are  the  control  and  data  management,  as  well  as  the  IR  interface,  to 
include  noise  reduction.  Once  a  cost  trade-off  decision  is  chosen,  the  change  to  any  of  the 
parameters  will  result  in  a  large  impact  to  cost  and  schedule.  Additional  changes,  to 
include  updates  to  technology  or  any  other  innovation  that  could  reduce  operational  risk 
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to  the  program  would  also  impact  cost  and  schedule,  with  possible  increases 
performance. 

The  requirement  to  select  a  single  sensor  to  maintain  lower  cost  is  a  key  element 
in  the  drawbacks  of  a  monolithic  system.  Although  selection  of  multiple  sensors  will 
result  in  higher  cost  with  regard  to  payload  design,  the  ability  to  diversify  the  payloads 
between  satellites,  therefore  limiting  the  size  and  weight  of  each  platfonn,  may  result  in 
the  deployment  costs  for  multiple  small  satellites  comparing  favorably  to  the  deployment 
of  a  single  system. 

Additional  benefits  of  a  SBG  are  the  separate  design  and  production  pipelines  that 
can  be  used.  Each  individual  element  can  be  built  independent  of  the  others,  allowing  the 
communications  satellite  subsystem  to  be  decoupled  from  system  payload  requirements. 
This  allows  for  rapid  development  and  deployment  of  the  system.  The  development 
structure  can  be  viewed  as  a  system  of  systems  with  a  larger  control  of  the  systems  in 
development,  allowing  for  limited  problems  of  synchronization  implementation.  If  a 
sensor  platfonn  falls  behind  schedule,  at  least  a  partially  capable  system  can  be  deployed, 
awaiting  the  completion  of  the  remaining  parts.  These  remaining  parts  can  join  the 
deployed  system  at  a  later  time  (Orndorff  &  Zink,  2010). 

b.  Operation  and  Reliability 

The  operation  of  a  system  is  dependent  on  each  component  of  the  system,  and 
their  reliability  in  both  singular  operation  and  successful  integration  with  the  spacecraft 
and  ground  stations,  as  required.  The  payload  data  collection  processing  by  the  onboard 
system  is  a  large  limitation  to  a  monolithic  system.  An  image  sensor,  as  provided  by  the 
FireSat  example,  can  allow  for  high  data  rates  and  large  signal  processing  meeting  the 
design  capability  of  the  sensor  (Apgar  et  ah,  1999).  Often,  the  ability  of  the  satellite’s 
communication  or  processing  systems  to  meet  the  sensor’s  capability  limits  the  amount  of 
data  provided  by  the  system.  This  requires  natural  tradeoffs  to  meet  the  system 
requirements,  and  processing  to  adjust  the  information  provided  from  the  sensor  to  the 
operator. 
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Payload  control  and  data  management  onboard  a  satellite  platfonn  require 
analysis  of  architectural  options  in  order  to  detennine  the  best  course  of  action  with  the 
lowest  impact  to  cost.  SMAD  provides  an  example  of  these  architectural  comparisons  for 
FireSat  in  table  16-22  on  page  679  (Apgar  et  ah,  1999).  The  table  displays  different 
processor  and  interface  options  and  the  resultant  pros  and  cons  of  each  of  the  four 
options.  The  requirements  of  a  satellite  to  perform  the  processing  of  sensor  data  increases 
the  complexity  of  the  design,  adding  cost,  complexity,  and  weight  to  accommodate  the 
number  of  general  processors;  or  reducing  the  reliability  of  the  system  to  provide  the 
requisite  threshold  needs  in  order  to  save  cost  by  reduction  in  processing  capabilities.  The 
final  detennination,  as  made  in  SMAD,  is  to  utilize  a  full  Field  of  View  sensor  with  two 
processors  (Apgar  et  ah,  1999). 

Utilizing  an  SBG  design,  the  gathered  data  can  be  off  loaded  from  the  sensor 
platform  to  the  communication  hub,  or  a  separate  processing  satellite.  The  utilization  of  a 
separate  satellite  for  processing  data  allows  for  a  reduction  of  power  requirements  of  the 
sensor  satellite.  This  reduction  in  power  allows  for  a  reduction  in  complexity  of  the 
satellite. 


c.  Repairability 

The  monolithic  structure  of  FireSat  allows  for  coverage  and  detection  through  the 
utilization  of  two  satellites,  placed  in  90  deg  offset  orbits  (Apgar  et  ah,  1999).  The 
highest  danger  to  cost  and  operation  of  this  type  of  system,  as  expressed  by  Brown  and 
Eremenko,  is  that  a  loss  in  an  element  will  result  in  a  complete  loss  of  capability;  whereas 
a  SBG  leads  to  a  reduction  in  capability  as  a  result  of  the  individual  module  that  failed 
(2006b).  Monolithic  systems  have  several  options  in  the  event  of  a  failure  of  a 
component,  either  repair  or  replace  the  component  on  orbit,  or  dispose  of  the  current 
satellite  and  replace  it  with  an  operational  system.  The  feasibility  of  repairing  or 
replacing  onboard  components  while  in  orbit  is  only  found  in  a  single  instance  in  current 
spacecraft  history,  and  that  is  the  Hubble  Space  Telescope.  As  a  result  of  the 
decommissioning  of  the  shuttle  fleet,  there  are  currently  no  satellites  or  servicing 
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spacecraft  in  operation  capable  of  providing  reparability  services  to  Hubble.  Replacement 
of  an  entire  satellite  is  the  only  recourse  for  a  failed  major  system  component  that  does 
not  include  a  redundancy. 

A  SBG  system  reduces  the  cost  of  the  replacement  of  components,  as  only  a 
single  module  is  needed,  vice  the  entire  constellation.  It  allows  for  a  new  component  to 
be  placed  into  the  wireless  network,  enabling  the  ability  to  replace  components  without 
the  need  for  complex  robotic  servicing  (Sahel,  2006).  An  imaging  system,  such  as 
FireSat,  is  not  restricted  by  the  mean  reliability  risk  of  the  many  components  necessary  to 
achieve  the  detection  of  wild  fires.  Each  component  can  be  individually  replaced  in  the 
event  of  failure.  Additionally,  each  component  can  theoretically  by  replaced  in  the  event 
of  large  technological  improvements,  allowing  for  requirements  to  be  adjusted  over  the 
lifetime  of  the  system,  by  just  allowing  deployment  of  additional  modules  (Brown  & 
Eremenko,  2006a).  This  simple  change  in  architecture  provides  a  means  to  distribute 
schedule  and  operation  risk,  reducing  overall  cost  of  the  program. 

4.  Launch  Segment 

The  capability  to  deliver  a  space  system  to  orbit  is  an  additional  factor  that  can 
greatly  impact  the  size  and  weight  allowed  for  a  satellite.  If  unaccounted  for,  the  launch 
system  could  result  in  major  delays  in  a  program  due  to  redesign  to  match  the 
requirements  of  the  desired  launch  system.  There  are  several  considerations  to  make 
when  choosing  a  launch  vehicle;  and  the  ability  to  launch  several  SBG  segments  in  one 
launch  is  a  consideration  that  could  result  in  reduced  program  costs. 

SBG  architecture  allows  for  reduction  in  the  size  of  the  system,  payload,  and 
propulsion  systems.  This  allows  for  the  flexibility  to  select  from  many  different  launch 
vehicles  (Orndorff  &  Zink,  2010).  In  modeling  a  SBG  system,  the  cost  impact  is  reduced 
because  of  the  small  size  of  the  satellite,  allowing  individual  modules  to  launch 
separately  on  smaller  vehicles,  or  as  add-ons  to  other  launches.  Additionally,  De  Week 
states,  when  calculating  the  launch  costs  to  achieve  99.9  percent  probability  of  successful 
on-orbit  operations,  the  reasonable  launch  cost  and  fractionation  penalty  assumption 
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result  in  launch  costs  reduction  in  two  or  more  than  a  traditional  system.  This  analysis 
removes  the  potential  of  a  SBG  system  providing  value  if  all  modules  do  not  make  it  to 
orbit  (De  Week  et  al.,  2004). 

Analysis  and  research  done  by  the  SMAD  authors  detennined  the  most  cost 
effective  launch  system  would  be  the  Pegasus  rocket.  Calculations  of  the  FireSat  system 
provide  approximately  225  kg  of  total  satellite  weight.  Based  on  the  Pegasus  User’s 
Guide  Release  6.0,  the  Pegasus  launch  system  can  deliver  FireSat  to  the  requisite  orbit, 
as  seen  in  Figure  6  ( Pegasus  User’s  Guide,  2007). 
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Figure  6.  Pegasus  XL  without  Hydrazine  Auxiliary  Propulsion  System  Performance 
Capability  (from  Pegasus  User ’s  Guide,  2007,  p.  11). 


The  SBG  design  comparison  results  in  a  reduction  of  total  weight  to  85kg.  The 
separation  of  the  communication  suite  from  the  imaging  platform  also  reduces  the  size  of 
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the  sensor  platfonn,  allowing  the  analysis  of  placing  several  satellites  in  the  Pegasus  XL 
launch  system. 


5.  System  Communications 

The  backbone  of  each  and  every  space-based  system  is  communications.  This  is 
no  less  true  for  nanosatellites  in  LEO  than  for  military  communications  satellites,  such  as 
the  Advanced  Extreme  High  Frequency  system.  Communications  are  required  to  transmit 
payload  information  to  the  desired  ground  stations,  provide  Telemetry,  Tracking,  and 
Control  (TT&C),  and  afford  relay  of  information  between  satellites,  in  some  cases. 

Within  a  monolithic  construct,  each  satellite  is  comprised  of  the  communications 
downlink  as  well  as  TT&C  uplink  components.  This  is  another  piece,  including  the 
sensor  payload  and  the  processing  and  storage  required  for  that  payload,  which  drives  up 
costs.  The  communications  requirement  adds  power  and  weight  to  the  overall  satellite 
design,  and  those  elements  grow  with  the  complexity  required  of  the  communications 
suite. 

The  following  section  examines  the  difference  between  the  requirements  of 
satellite  to  satellite  communications  and  that  of  a  ground  communications  link  that  would 
be  established  for  a  SBG. 

a.  Space-Based  Communications 

A  benefit  of  a  SBG  is  that  the  core  communication  satellite,  or  central  hub, 
provides  a  dedicated,  high-bandwidth  ground  link  that  is  several  times  larger  than  a  single 
satellite  system,  allowing  for  transmission  of  hundreds  or  more  megabits  (Orndorff  & 
Zink,  2010). 

Operational  today,  there  are  a  few  examples  of  satellites  that  utilize  space 
communications,  relaying  information  from  one  satellite  to  another.  These  typical 
satellites  convey  large  communications  packages,  often  times  allowing  for  seamless 
communications  between  command  nodes  across  the  world.  A  SBG  system  is  fully 
dependent  on  space  based  communications,  if  at  a  smaller  scale,  than  most  global  or 
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planetary  relay  systems.  Communications  between  systems  in  a  SBG  involves  just  a 
replacement  of  the  current  monolithic  data  bus  structure,  and  replacing  it  with  wireless 
data  links  between  the  individual  satellites  (Saleh,  2006). 

SBG  architecture  is  fixed  around  a  centralized  communications  hub,  which  would 
serve  as  the  pathway  for  TT&C  and  sensor  data.  Each  additional  module  is  designed  such 
that  it  could  join  and  integrate  into  the  hub  LAN,  similar  to  current  terrestrial  wireless 
networks  available  around  the  world.  This  enables  a  hub  and  spoke  system  configuration, 
allowing  the  communication  satellite  to  contain  the  router  for  the  LAN  (Orndorff  &  Zink, 
2010).  The  network  would  allow  for  positional  and  health  data  from  each  spoke  to  be 
independently  reported  to  the  hub  system.  An  example  of  this  is  approached  in  the  F6  and 
the  Mission-Aware  Network  Architecture  for  Small-Satellite  Adaptive  Systems 
(MANASSAS).  These  systems  utilize  a  cognitive  networking  approach,  giving  the 
systems  the  ability  to  change  and  modify  its  behavior  in  flight.  This  allows  for  a 
significant  enhancement  in  a  systems  effectiveness  and  flexibility  (Waite,  2011). 

The  TT&C  of  individual  modules  would  be  relayed  through  the  communications 
hub.  Orndorff  and  Zink  propose  that  each  module  should  contain  its  own  capability  of 
detennining  its  location,  utilizing  GPS  or  star  and  horizon  trackers  (Orndorff  &  Zink, 
2010).  While  a  GPS  system  is  adequate  for  a  Low  Earth  Orbit  (LEO)  system,  Medium 
Earth  Orbit  and  GEO  systems  would  require  the  use  of  stellar  locating  sensors,  further 
complicating  the  system  architecture.  A  separate  location  computation  could  utilize 
interferometer  architecture.  This  would  require  each  module  to  report  infonnation  on 
different  frequencies.  This  would  allow  a  single  interferometer  to  establish  the  relative 
position  of  each  module,  and  utilize  its  own  location  device  to  relay  the  full  details  of  the 
constellation  position  to  the  TT&C  stations.  The  utilization  of  interferometers  is  prevalent 
in  several  terrestrial  systems,  to  include  the  new  P-8A  Poseidon  aircraft,  which  uses 
interferometer  measurements  to  accurately  maintain  current  locations  of  sonobuoys  based 
on  relative  location  to  the  aircraft,  and  the  aircraft’s  geolocation  (Department  of  the  Navy 
Office  of  the  Chief  of  Naval  Operations,  2014). 
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The  concept  of  SBG  systems  is  to  utilize  current  wireless  technology  to  achieve 
the  constellation  integrated  LAN.  There  are  several  different  options  to  examine  in 
detennining  the  best  system  to  select  for  this  LAN.  Initial  studies  indicate  that  RF 
transmissions  are  more  favorable  at  distances  below  several  hundred  meters,  with 
modular  distance  of  several  kilometers  favoring  laser  transmissions.  The  highly  favorable 
frequency  bands  for  RF  are  the  V  or  W  band  (Sahel,  2006).  An  experiment  conducted 
onboard  the  Mir  space  station,  designated  at  the  Mir  Wireless  Network  Experiment 
(MWNE)  provided  risk  mitigation  for  the  ISS,  in  proving  the  concept  of  a  space  based 
wireless  network.  The  MWNE  was  conducted  onboard  the  Space  Shuttle  mission  STS-74 
and  Mir.  The  experiment  operated  a  2.4  GHz  wireless  network  at  a  power  output  of 
50mW  (Lofton  &  Conley,  1997).  This  concept,  although  not  perfonned  for  satellite  to 
satellite  communications,  does  provide  the  basis  that  a  2.4  GHz  network  can  be 
established  between  systems  in  orbit. 

Current  wireless  technology  allows  for  transmission  on  2.4  GHz  or  5  GHz 
frequency  bands,  operating  with  an  average  power  output  of  20  dBm.  This  design, 
assuming  a  wireless  link  based  on  current  802.1 1  series,  weighs  tens  of  pounds,  requires 
little  power,  and  fit  into  small  spaces,  even  when  including  a  12  dB  antenna  for 
transmission  (Orndorff  &  Zink,  2010).  In  this  study,  a  wireless  link  of  2.4  GHz  was 
utilized,  as  this  frequency  spectrum  has  been  previously  tested  in  spaceflight,  as 
referenced  in  Lofton  and  Conley  MWNE  report  (1997).  Several  wireless  LAN  systems 
on  the  market  today  allow  for  dual  transmission  on  these  frequencies.  The  router 
examined  in  this  research  was  the  Asus  RT-AC68U,  based  on  a  top  pick  by  CNET.com 
reviewers.  As  a  top  pick,  the  router  provided  a  continuous  381  Mbps  throughput  speeds  at 
a  distance  of  30  m,  which  was  stated  as  “still  very  impressive”  (Ngo,  2014).  The 
assumption  is  that  due  to  the  decrease  in  atmospheric  attenuation,  the  router  would  prove 
as  capable  at  a  50  m  distance,  as  compared  to  the  30  m  in  an  Earth  bound  test.  This 
router,  even  as  a  larger  model,  has  a  weight  of  only  26.3  oz.,  takes  up  a  total  of  0.00234 
m3  (Ngo,  2014). 
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b.  Ground  Communications 

An  additional  requirement  of  every  space  based  system  is  the  communications  of 
data  to  the  user,  and  directives  to  the  system.  The  required  downlink  to  the  ground 
station,  as  simply  described  by  Jerry  Sellers,  is  information  on  the  health  and  status  of  the 
spacecraft  as  well  as  the  designed  payload.  This  link  has  the  largest  amount  of  data  to 
transport,  and  as  a  result,  is  often  the  limiting  factor  in  the  amount  of  infonnation  that  can 
be  collected,  stored,  and  transmitted.  When  examining  the  varying  requirements  of  a 
SBG,  there  are  two  primary  avenues  to  explore  in  detennining  the  architecture  of  the 
ground  communications  network. 

(1)  Single  Site  Support 

Single  site  support  architecture  is  what  is  primarily  utilized  in  today’s  space 
missions.  The  construct  that  information  from  the  downlink,  as  well  as  the  uplink,  is 
focused  under  a  single  unit,  often  with  various  link  locations  throughout  the  country  or 
world.  For  utilization  in  SBG  architecture,  this  would  form  as  a  central  network  storage 
area,  similar  to  the  network  cloud  concept  being  utilized  by  several  different  companies 
today.  All  of  the  infonnation  gathered  by  all  the  satellites  would  be  transmitted  to  a 
central  location,  with  each  payload  being  specifically  encoded  for  cataloging  in  the 
network.  This  would  require  several  link  sites,  and  a  large  area  for  processing  and  storage 
of  the  data,  so  that  users  could  retrieve  the  data  as  needed.  This  is  simplistic,  in  that  the 
basic  parameters  of  the  architecture  are  developed,  and  only  the  catalog  and  distribution 
of  payload  information  would  need  specific  development  per  program. 

(2)  Mission  Specific  Site  Supports 

A  mission  specific  site  support  would  be  ideal  for  a  massive  SBG  undertaking 
that  included  a  mixture  of  civilian  and  DOD,  or  open  and  sensitive  information.  It  would 
ensure  that  data  would  be  downloaded  to  sites  only  designated  to  receive  that 
information,  limiting  the  ease  of  sensitive  information  being  leaked  or  intercepted.  The 
architecture  to  utilize  this  type  of  support  is  not  as  widely  utilized  in  today’s  market.  It  is 
further  complicated  within  a  SBG  construct.  A  mission  specific,  multi-site  support  would 
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require  the  communication  hub  to  be  capable  of  individually  transmitting  data,  based  on  a 
type  of  encoding  or  encryption,  to  a  specific  site.  Due  to  the  inevitability  of  having  more 
than  one  site  within  the  communication  field  of  view,  it  would  also  require  the  ability  to 
perform  a  downlink  on  different  frequencies,  to  ensure  no  cross  link  of  data  flowing  at 
the  same  time.  This  architecture,  while  beneficial,  may  result  in  an  undesired  cost 
increase  of  a  program,  due  to  these  requirements. 

To  allow  for  direct  analysis,  a  NASA  Tracking  and  Data  Relay  Satellite  (TDRS) 
was  used  as  a  currently  operational  system  that  could  provide  the  functions  desired  of  the 
communications  hub  for  a  SBG.  The  TDRS  currently  provides  simultaneous  relay 
between  ground  stations  and  multiple  satellites  (Bell,  2014).  The  scope  of  a 
communications  hub  would  be  reduced  slightly,  in  that  the  satellite  would  only  be 
required  to  connect  to  the  wireless  network,  and  not  be  responsible  for  relay  to  multiple 
systems  within  different  orbits.  SMAD  provides,  in  table  20-16,  as  Space  Systems  cost 
estimate  of  each  TDRS,  which  estimates  an  average  cost  of  $172  million  per  unit  (Apgar 
et  ah,  1999).  More  information  on  the  capabilities  of  TDRS  can  be  found  on  the  NASA 
Space  Communications  and  Navigation  web  site  (Mai,  2013). 

Separating  the  sensor  element  from  the  communication  suite  of  a  single  unit  can 
give  increased  capability,  but  it  does  add  additional  costs  to  the  program.  The  cost 
savings  are  realized  within  the  combination  of  several  sensor  units,  each  utilizing  a  single 
communications  hub,  for  data  transmission  and  reception.  The  communications  platform 
would  add  to  the  program  cost,  but  the  effectiveness  of  adding  several  sensors  under  a 
single  program  would  result  in  overall  cost  savings. 

D.  CHAPTER  SUMMARY 

The  research  completed  and  analyzed  in  this  chapter  shows  the  specific 
correlations  and  explicit  detailed  differences  between  a  common  monolithic  space  system 
and  that  of  a  SBG  system.  Each  area  examined  is  required  for  detailed  acquisitions,  and 
must  be  done  in  conjunction  with  all  others  in  order  to  prevent  delays  and  cancellations  in 
a  program.  Each  section  provided  the  required  inputs  and  resulting  outputs  for  the  FireSat 
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SBG  system.  All  data  inputs  and  outputs  calculated  for  FireSat  SBG  Sensor  Design  can 
be  found  in  Figure  7  thru  Figure  14  appendix. 

The  DARPA  F6  project  is  a  prime  example  of  a  program  omission  that  resulted  in 
a  million  dollar  system  being  canceled,  in  that  the  program  lacked  an  overall  integrator. 
Additionally,  Brad  Tousley  stated  that  the  system  was  not  focused  on  a  traditional 
mission  set,  “only  data  transfer — there  was  nothing  else  happening”  (Ferster,  2013). 


36 


IV.  APPLICATION  OF  STUDY 


A.  ANALYSIS  SUMMARY 

The  previously  stated  research  and  analysis  conducted  provides  a  breakdown  of  a 
monolithic  imaging  platform  into  a  SBG  sensor  system,  and  the  estimated  cost  savings  of 
that  single  system.  It  shows  how  removing  the  communications  component  from  the 
sensor  platform  would  change  the  overall  structure  of  the  architecture  requirements,  and 
how  this  separation  can  benefit  a  program.  The  following  chapter  utilizes  the  assumption 
that  the  majority  of  systems  would  experience  the  same  relative  cost  savings,  and  shows 
the  estimated  program  savings  when  combining  FireSat  with  three  currently  operational 
systems  in  orbits.  The  systems  utilized  were  the  Fermi  Gamma-ray  Space  Telescope 
(FGST),  Galaxy  Evolution  Explorer  (GALEX),  and  Swift  Gamma  Ray  Burst  Explorer 
(SWIFT)  spacecraft.  These  systems  were  selected  due  to  their  relatively  close  orbital  and 
inclination  to  each  other,  and  the  assumption  FireSat  could  operate  within  those 
parameters.  Additionally,  these  sensor  payloads  all  utilize  an  imaging  type  sensor,  so  a 
general  relationship  can  be  made  between  them.  Table  4  provides  basic  details  on  each 
system.  Further  information  can  be  found  on  the  NASA  National  Space  Science  Data 
Center  (Bell,  2014).  An  estimated  payload  size  was  detennined  based  on  a  default 
assumption  that  the  payload  was  approximately  26  percent  of  the  total  spacecraft  weight. 
The  space  segment  portion  of  the  cost  analysis  was  used,  assuming  the  operational  costs 
between  a  fully  monolithic  system  and  a  SBG  sensor  would  be  similar,  due  to  the  mission 
being  unchanged.  This  is  a  rough  assumption,  as  the  type  of  ground  architecture  utilizing 
a  single  point  download  system,  as  described  earlier,  could  reduce  the  cost  of  the  program 
due  to  the  reduction  in  overall  footprint  required  of  the  systems  as  a  whole.  Additionally, 
the  launch  costs  were  not  included,  as  the  launch  platfonns  of  the  original  systems  was 
not  researched. 
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Table  4.  System  Example  Parameters  (from  Bell,  2014) 


System 

NORAD  ID 

Perigee 

(km) 

Apogee 

(km) 

Inclination 

(deg) 

Total 

Mass 

(kg) 

Estimated 
Payload  Size 
(kg) 

FireSat 

Example 

700.0 

700.0 

55.0 

175.0 

28.1 

FGST 

33053 

527.9 

545.9 

25.6 

4303 

1160 

GAFEX 

27783 

685.3 

690.3 

29.0 

280.0 

75.6 

SWIFT 

28485 

554.0 

570.8 

20.6 

1470 

397 

B.  COST  COMPARISONS 

This  cost  savings  detennined  are  primarily  found  in  the  R&D  and  manufacturing 
of  the  system  architecture.  The  cost  savings  are  fully  realized  when  combining  several 
systems  into  a  single  architecture  system,  due  to  the  savings  provided  by  a  sensor  only 
platform,  when  compared  to  the  monolithic  system.  Additional  savings  include  reliability 
of  each  module  and  module  replacement;  however  those  specific  topics  were  not  fully 
researched. 

The  cost  analysis  of  FireSat  was  compiled  utilizing  the  data  found  in  the 
Appendix,  compared  to  the  results  provided  in  SMAD,  specifically  utilizing  table  20-24 
on  page  816.  The  $60.1  million  estimate  was  based  on  the  Small  Satellite  Cost  Model 
(SSCM)  provided  in  table  20-6.  This  space  based  cost  was  approximately  44  percent  of 
the  total  estimated  total  cost  of  the  system  over  5  years,  as  provided  by  table  20-24 
(Apgar  et  al.,  1999).  The  space  segment  sum  of  components  estimated  cost  of  the  sensor 
FireSat  system,  as  a  result  of  the  limited  communications  requirement,  resulted  in  a  cost 
of  $23.9  million,  saving  just  over  $36  million  (60  percent)  as  compared  to  the  SMAD 
estimate. 

A  cost  analysis  of  the  four  systems,  developed  as  only  sensor  platfonns,  and  the 
addition  of  a  TDRS  type  communication  hub  was  done  to  fully  realize  the  savings 
capable  of  SBG  architecture.  In  order  to  remain  within  the  scope  of  this  thesis,  a  few 
assumptions  were  made  toward  the  three  operational  systems. 
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•  The  space  segment  cost  of  each  system  matched  FireSat,  in  that  it  was  44 
percent  of  the  total  operational  cost 

•  The  reduction  to  a  sensor  only  platfonn  reduced  the  space  segment  cost  of 
each  system  to  40  percent  of  the  original  space  segment  cost,  as  per  the 
FireSat  example. 

•  The  TDRS  cost  accurately  represents  the  space  segment  cost  of  a 
communication  hub. 

The  total  lifetime  cost  of  each  operational  system  was  researched  and  converted 
into  FY15  dollars,  and  was  determined  to  be  $233.2  million  for  FGST  (SLAC  National 
Acceleration  Laboratory,  2007),  $160.8  million  for  GALEX  (Clark,  2012),  and  $317.7 
million  for  SWIFT  (Neal,  2004).  Under  the  assumption  each  system  followed  a  similar 
cost  fallout  as  described  in  earlier  chapters,  in  that  70  percent  of  costs  were  utilized  for 
acquisitions,  Table  5  provides  a  breakdown  of  lifetime  cost  to  estimated  SBG  Space 
Segment  cost. 


Table  5.  Space  Segment  Cost  Analysis  Results 


System 

Operational 

Cost 

($M) 

Estimated 

Space 

Segment 

Cost 

($M) 

Estimated 
SBG  Space 
Segment 
Cost 
($M) 

FireSat 

$85.86 

$60.1 

$23.9 

FGST 

$233.2 

$163 

$65.3 

GALEX 

$160.8 

$113 

$45.0 

SWIFT 

$317.7 

$222 

$90.0 

Upon  combining  all  four  systems  into  a  SBG,  the  expected  savings  is 
approximately  $224  million.  When  combining  with  the  TDRS,  with  a  unit  cost  of  $172 
million,  the  total  savings  provided  by  the  SBG  space  segment  alone  is  $52  million. 
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c. 


RECOMMENDATIONS 


This  thesis  presented  arguments  that  SBG  architectures  could  provide  beneficial 
improvements  that  can  result  in  reduced  cost  of  a  space  system.  A  detailed  breakdown  of 
an  example  system  combined  with  assumed  similarities  to  three  additional,  currently 
operational  systems,  shows  that  there  is  a  realistic  cost  savings  to  the  space  segment 
alone,  when  combining  multiple  systems  into  SBG  architecture.  Research  also  theorizes 
that  SBG  architecture  could  provide  a  level  of  flexibility  without  resulting  in  an  increase 
in  cost  when  adding  additional  sensors  to  orbit,  as  compared  to  current  concepts. 

A  broad  analysis  was  done  by  Charlotte  Mathieu  (2006)  in  her  paper  assessing  the 
fractionated  spacecraft  concept.  Her  conclusion  was: 

Fractionated  spacecraft  could  deliver  more  value  to  customers  than 
traditional  ones  for  a  given  mission  and  at  a  given  level  of  performance. 

As  demonstrated  in  the  architectural  analysis,  the  more  fractionated  the 
architecture  is,  the  more  expensive  it  is.  But  in  terms  of  value  delivered  to 
potential  customer  the  “best”  fractionated  architectures  are  different  in 
various  fields  of  application  (communications,  navigation,  etc.),  (p.  136) 
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V.  CONCLUSIONS 


This  thesis  researched  the  development  of  a  SBG,  focusing  on  the  estimated 
advantages  as  well  as  an  estimated  cost  savings  for  the  space  segment  architecture.  The 
full  realization  of  cost  savings  requires  further  research,  but  initial  analysis  shows  that 
there  is  a  point  in  which  cost  savings  will  be  understood  with  a  SBG  over  a  monolithic 
architecture. 

A.  KEY  POINTS  AND  RECOMMENDATIONS 

The  thesis  attempted  to  answer  two  questions. 

•  Can  the  SBG  architecture  reduce  cost  of  space  systems? 

Research  and  analysis  of  FireSat,  as  provided  by  fonnulas  in  SMAD,  shows  that 
approximately  60  percent  of  savings  per  system  can  be  gained.  When  combining  several 
systems  together,  this  cost  will  offset  a  requirement  to  have  a  centralized  communication 
hub  for  SBG  architecture. 

•  Could  a  SBG  allow  mission  flexibility  without  substantial  cost  increases? 

Research  provides  examples  of  how  the  flexibility  SBG  could  provide  throughout 

a  system’s  lifecycle  can  save  millions  of  dollars  in  expenses.  This  savings  is  difficult  to 
fully  capture,  as  it  is  dependent  of  the  specifics  of  each  architecture,  however  a  safe 
hypothesis  is  that  the  added  flexibility  provide  will  not  increase  cost,  and  may  prove  to 
decrease  the  costs  over  a  system’s  lifetime. 

The  SBG  architecture  shows  promise  in  having  the  capability  to  provide  the  DOD 
with  cost  effective  space  systems,  and  could  result  in  a  whole  new  paradigm.  Research 
done  by  Ms.  Mathieu  (2006)  shows  that  private  sector  organizations  have  little  incentive 
to  move  toward  a  fractionated  architecture,  but  the  government  has  the  best  position  to 
enable  this)  transition  to  SBG  systems.  This  requires  focused  research  and  contracting  in 
order  to  ensure  mission  capability  and  integration  is  captured.  The  DARPA  F6  project  is 
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a  casualty  of  this  lack  of  focus,  and  will  result  in  further  delay  in  acceptance  of  SBG 
architectures  for  future  implementation. 

B.  AREAS  FOR  FUTURE  RESEARCH 

The  research  presented  in  this  thesis  took  a  defined  separation  of  a  sensor 
platform  and  the  communication  suite,  and  adding  three  similar  systems  to  the 
architecture  to  realize  an  estimated  cost  savings  to  the  space  segments  of  these 
architectures.  Further  research  and  analysis  should  be  done  to  attempt  to  capture  cost 
savings  in  relation  to  communications  and  operations  of  SBG,  as  well  as  risk-cost 
comparisons  that  a  SBG  provides.  The  risk-cost  comparison  includes  further  system 
fractionation,  reliability  benefits  with  SBG  elements,  and  mission  complexity 
requirements  as  a  result  of  fractionated  systems.  In  specifics  to  reliability,  Brown  and 
Eremenko  express  the  benefit  in  the  quote: 

If  treated  as  a  design  parameter  endogenous  to  the  design  process,  the 
reliability  of  each  module  can  be  independently  set  to  maximize  the  net 
value  delivered  by  the  system  in  light  of  considerations  such  as:  the 
different  paces  of  obsolescence  for  different  technologies  may  make  the 
early  replacement  of  some  modules  (most  notably  C&DH)  desirable;  the 
cost  of  implementing  a  given  degree  of  reliability  may  be  starkly  different 
across  modules;  and  the  degree  to  which  the  health  of  a  particular  module 
is  vital  to  the  capability  of  the  overall  system  (i.e.,  its  covariance  with  the 
other  modules)  may  differ  depending  on  the  system  architecture,  degree  of 
homogeneous  fractionation,  and  the  types  of  connectivity.  (2006.  p.  10) 

Additionally,  technological  advances  over  extended  life  mission  should  be 
considered,  as  obsolescence  does  not  threaten  the  entire  system,  just  the  single  portion 
that  platform  is  placed  (Omdorff  &  Zink,  2010). 
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APPENDIX:  FIRESAT  SBG  SENSOR  DESIGN 


Circular  orbit  altitude 

'00.000 

700.000' 

km 

Atmospheric  Perturbations 

Semi-major  axis 

7078.137* 

km 

Drag  coefficient 

3.13  ^ 

Inclination 

98.19* 

deg 

Ballistic  coefficient  Set  to  value  | 

60.39 

21.37  60.39  "  kg/m  2 

Eccentricity 

0.0000 

o.oooo* 

Atmospheric  scale  height 

99.3  "  km 

Perigee  altitude 

N/A  " 

km 

Apogee  altitude 

N/A  ' 

km 

Min 

Mean  Max 

Atmospheric  density 

5.74E-15 

2.72E-14  1.47E-13  kg/m  3 

Repeating  ground  tracks 

Number  of  orbits 

Change  in  semi-major  axis 

-1.593E-01 

-7.549E-01  -4.080E+00  km/yr 

Number  of  days  Set  to  value  | 

Change  in  eccentricity 

N/A 

N/A  N/A  per  day 

Orbit  lifetime 

6.233E+02 

1.315E+02  2.434E+01  years 

Basic  Dynamics 

Orbit  period 

98.7  f 

min 

Orbit  revolutions  per  day 

14.58 

revs/day 

Gravitational  Perturbations 

Orbit  energy 

-28. 16" 

kmA2/secA2 

Node  precession  rate  -  J2 

9.856E-01* 

deg/day 

Average  orbit  angular  velocity 

1.0602E-03" 

rad/s ec 

Node  precession  rate  -  Moon 

3.302E-05* 

deg/day 

Average  ground  velocity 

6.76' 

km/sec 

Node  precession  rate  -  Sun 

1.504E-05" 

deg/day 

Total  node  precession  rate 

9.856E-01 

deg/day 

Satellite  velocity  (circular) 

7.504" 

km/sec 

Escape  velocity  (circular) 

10.613" 

km/sec 

Node  spacing 

-24.69" 

deg/rer 

Sun  synchronous  inclination 

98.19" 

deg 

Satellite  velocity  (at  perigee) 

N/A  " 

km/sec 

Escape  velocity  (at  perigee) 

N/A  " 

km/sec 

Perigee  rotation  rate  - 12 

N/A  " 

deg/day 

Perigee  rotation  rate  -  Moon 

N/A  " 

deg/day 

Satellite  velocity  (at  apogee) 

N/A  " 

km/sec 

Perigee  rotation  rate  -  Sun 

N/A  " 

deg/day 

Escape  velocity  (at  apogee) 

N/A  " 

km/sec 

Total  perigee  rotation  rate 

N/A 

deg/day 

Figure  7. 

Orbital  Inputs 
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Altitude 

700.000' 

kni 

Angular  radius  of  the  planet 

64.3  0" 

deg 

Elevation  angle 

20.00 1  20.00' 

deg 

Swath  width 

24.28' 

deg 

Nadir  angle 

57.86' 

deg 

Swath  width 

2702. 598^ 

km 

Max  range 

1583.933' 

km 

Angular  field  of  view 

115.72' 

deg 

Object  plane  radius 

12.14* 

deg 

Object  plane  radius 

1351.299* 

km 

Wavelength 

4.830E-0? 

m 

Ground  resolution  at  nadir 

1.00  | 

1.00*  m 

Ground  resolution  at  max  range 

6.62*  m 

Angular  resolution 

1.4291-06'  rad 

Pixel  size 

4.2861  06'  m 

Pixel  ground  resolution  at  nadir 

1.00*  m 

Pixel  quality  factor 

1.000 

1.000* 

Pixel  angular  resolution 

Number  of  pixels 

1.429E  06*  rad 
1413813* 

Aperture  diameter 

0.825'  m 

F  Number 

3.63? 

Focal  length 

3.000 

3.000'  m 

Numerical  aperture 

0.13? 

Image  plane  radius 

4.775*  m 

Magnification 

4.286E-06* 

Figure  8. 


Optics  Payload  Information 
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Existing  Instrument 
Aperture  diameter 


Number  of  pixels 
Bits  per  pixel 

Ground  velocity 

Pixel  ground  resolution  at  nadir 

Scan  time  per  image  (for  staring  sensor) 


1.000 


1.000 


New  Instrument 

Aperture  diameter 


0260 


Pavload  -  Data  Rate 


1413813' 

00 

<=>J 

Data  storage  -  scanning  sensor 
Data  production  rate  -  scanning  sensor 


10.00 


10.00  sec 


Orbit  period 

98.7? 

Storage  time  (percent  of  orbit  penod) 

100.0%' 

Data  storage  -  other  sensor 
Data  production  rate  -  other  sensor 


0.260  m 

996421. 28*  km'2 


Linear  dimensions 

Number  of  "square"  images  (per  orbit) 

0.14' 

Side  1  (or  cylinder  length) 

1.50 

1.50' 

m 

Duty  cycle  (per  orbit) 

0.920%  | 

0.920%' 

Side  2  (or  cylinder  diameter) 

1.00 

l.oo' 

m 

Side  3  (if  rectangular) 

m 

Linear  dimensions  -  scaled 

Side  1  (or  cylinder  length) 

0.39 

ni 

Mass 

800.0 

800.0' 

kg 

Side  2  (or  cylinder  diameter) 

0.26 

m 

Power 

900.0 

900.0' 

W 

Side  3  (if  necessary) 

m 

Volume 

0.02' 

mA3 

Aperture  diameter  ratio 

0.260' 

Sizing  scale  factor 

2.00' 

Mass 

28.1' 

kg 

Mass  density 

1.36' 

gm/cmA3 

Peak  power 

31.6' 

W 

Power  density 

0.001526' 

W/cmA3 

Average  power 

oi" 

W 

4170071.5  Mb 
7.648E+10'  bps 


6762.1'  m/s 

Data  storage  -  staring  sensor 

87186889.2 

Mb 

1.000'  m 

Data  production  rate  -  staring  sensor 

1.599E+12' 

bps 

Mb 

bps 


Figure  9.  Payload  Physical  Sizing 
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Frequency 

2.400 

2.400" 

GHz 

Data  rate 

2.334E-09 

2.334E+09" 

bps 

Probability  of  Bit  Error 

1.001-0? 

Wavelength 

1.251-01" 

ni 

Required  Eb  No 

9.60" 

dB 

Ground  Transmitter 

Geometry  &  Atmosphere 

Spacecraft  Receiver 

Output  power 

0.01" 

XV 

Altitude 

0.050 

0.050" 

km 

Antenna  efficiency 

55.0%" 

Output  power 

-20.50 

-20.50" 

dB 

Planet  angular  radius 

89.7? 

deg 

Antenna  diameter 

0.0? 

m 

Line  loss 

-3.00" 

dB 

Elevation  angle 

deg 

Peak  antenna  gain 

2.15 1  2.1? 

dB 

Antenna  efficiency 

55.0%" 

Nadir  angle 

■51 

deg 

Half-power  beam  width 

127.42" 

deg 

.Antenna  diameter 

0.0? 

m 

Planet  central  angle 

deg 

Peak  antenna  gain 

2.15 

2.1? 

dB 

Propagation  path  length 

km 

Pointing  error 

1 

deg 

Half-power  beam  width 

127.4? 

deg 

Antenna  pointing  loss 

dB 

EIRP 

-21.3? 

dB 

Atmospheric  attenuation  at  zenith 

0.000 

o.ooo" 

dB 

Rain  attenuation 

0.000 

o.ooo" 

dB 

System  noise  temperature 

688.00" 

K 

Pointing  error 

12.74" 

deg 

Increase  in  system  noise  temp 

0.00" 

K 

GT 

26.23" 

dB/K 

Antenna  pointing  loss 

-0.12" 

dB 

Link  Budget 


Mass  Estimate 


EIRP 

Space  loss 

Atmospheric  attenuation 
Rain  attenuation 
GT 

Antenna  pointing  losses 

Eb/No 

C/No 


-21.3?  dB 
'  dB 
"  dB 
0.00"  dB 
-26.23'  dB 
'  dB 

"  dB 
"  dB 


Receive  Antenna 
Mass 


0.0  kg 


Implementation  loss 
Margin 


-2.00  dB 

'  dB 


Figure  10.  Uplink  Communications  Inputs 
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Frequency 

240 

2.40?  GHz 

Data  rate 

2.334E+09 

2.334E+0?  bps 

Probabilitv  of  Bit  Error 

1.00E-0? 

Wavelength 

i.’sr  of 

m 

Required  Eb  No 

9.6$ 

dB 

Spacecraft  Transmitter 

Geometry  &  Atmosphere 

Ground  Receiver 

Output  power 

o.of 

w 

Altitude 

0.050 

0.05?  km 

Antenna  efficiency 

S5.0«/o 

Output  power 

-20.00 

-20.0? 

dB 

Planet  angular  radius 

89.7f  deg 

Antenna  diameter 

o.of 

m 

Line  loss 

-J.oo'' 

dB 

Elevation  angle 

deg 

Peak  antenna  gain 

2-JS  | 

2.1? 

dB 

Antenna  efficiency 

5  5.0  “-o' 

Nadir  angle 

^  deg 

Half-power  beamwidth 

127.4? 

deg 

Antenna  diameter 

o.of 

m 

Planet  central  angle 

deg 

Peak  antenna  sain 

2.15 

’.if 

dB 

Propagation  path  length 

^  km 

Pointing  error 

12.74? 

deg 

Half-power  beam  width 

127.42^ 

deg 

Antenna  pointing  loss 

-0.1? 

dB 

EIRP 

-20.8? 

dB 

Atmospheric  attenuation  at  zenith 

0.000 

0.00?  dB 

Rain  attenuation 

0.000 

0.00?  dB 

System  noise  temperature 

260.0? 

K 

Pointing  error 

deg 

Increase  in  system  noise  temp 

0.00"  K 

GT 

-22.0? 

dB/K 

Antenna  pointing  loss 

dB 

Duty  cycle  (per  orbit  period)  Q 

loo.o  “V 

Link  Budget 

Mass  &  Power  Estimates 

EIRP 

-20.8?  dB 

Transmit  Antenna 

Space  loss 

’  dB 

Mass 

0.? 

kg 

Atmospheric  attenuation 

'  dB 

Rain  attenuation 

0.0?  dB 

GT 

-22.0?  dB 

TWTA  ' 

SSPA  " 

Antenna  pointing  losses 

'  dB 

Transmitter  mass 

2-3 

1.1 

kg 

Peak  transmitter  input  power 

8.4 

9.8 

W 

EbNo 

'  dB 

Average  transmitter  input  power* 

8.4 

9.8 

\V 

C/No 

"  dB 

Implementation  loss 

2.0?  dB 

Margin 

’  dB 

Figure  1 1 .  Downlink  Communications  Input 
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Payload  Mass 
Payload  Percentage 
Margin  Percentage  (Mass) 

Payload  Power  (peak) 
Payload  Percentage 
Margin  Percentage  (Power) 


28.  f 

50.0H* 

lS-Orf 

31.1? 

38.-1%'' 

15.0%'' 

Type  of  attitude  control  system  ^ 


Three-axis  (momentum  bias) 

□ 

Type  of  communications 

Single  uplink/downlink  antenna 

FI 

Traveling  Wave  Tube  Amplifier  (TWTA) 

FI 

Primary  power  source 

1  Solar  arrays  -  cylindrical,  body-mounted 

a 

Type  of  propulsion  system  * 

None 

a 

Type  of  structure 

j  Monocogue 

El 

Preliminary  Estimates'  Current  Estimates 


Mass 

Avg  Poster 

Miss 

Peak  Power  Avg  Power 

Size 

(kg) 

(W) 

(kg) 

(W) 

(W) 

Minimum 

Expected 

Maximum 

Payload 

28.1 

0J 

28.1  ' 

31.6  " 

0J  ' 

Spacecraft 

S.C  Subsystems 

28.0 

79.6 

46.1  ' 

60.7  , 

60.7  ' 

Volume 

0.43 

0.85 

4.27 

ADCS 

3.1 

15.1 

3.1' 

15.1' 

15.C 

Bodyr  area 

0.44 

1.21 

2.37 

C&DH 

1.6 

6.3 

If 

6.3' 

6.3' 

Linear  dim 

0.66 

1.10 

1.54 

Power 

10.9 

29.5 

3Zf 

30.  f 

30.  f 

Moment  of  inertia 

- 

16.54 

- 

Propulsion 

1.4 

4.9 

Of 

Of 

Of 

Structure 

8.4 

0.0 

0.1' 

0.0' 

Of 

Thermal 

1.3 

4.9 

If 

0.0' 

O.f 

TT&C  ( Communications ) 

1.3 

18.9 

2.C 

S.C 

S.C 

Margin 

14.0 

20.0 

11.1  ' 

13.8  ' 

9.1  ’ 

Solar  Array 

Area 

'  5.79 

mA2 

S,  C  Dry  Mass 

70.1 

85.3  ' 

Mass 

’  27.32 

kg 

Area  offset  (of  deployed  array) 

'  N/A 

mA2 

Propellant  Mass 

3.0 

0.0  ’ 

Moments  of  inertia  (of  deployed  array) 

Perpendicular  to  array  face 

N/A 

kg-mA2 

S  C  Loaded  Mass 

73.1 

85.3  ' 

Perpendicular  to  array  arris 

N/A 

kg-mA2 

S.  C  Power 

99.9 

106.1 

70.1  ' 

About  array  axis 

N/A 

kg-mA2 

Figure  12. 


Final  Design  Sizing  Input 
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Mass  Estimates  (with  margin) 

Other  Spacecraft  Information 

Heritage 

Payload  mass 

ilS  ke 

Type  of  payload 

Vtjibl*  Light 

a 

Payioad 

Moderate  modification*  to  existing  design 

w 

Spacecraft  bus  dry  mass 

5J.r  kg 

ADCS 

X6  kg 

Type  of  attitude  control 

Three-aws 

a 

S  C  Bus 

Moderate  modifications  to  existing  design 

▼ 

C&DH 

1.8"  kg 

Pointing  accuracy 

deg 

Power 

43  S  kg 

Pointing  knowledge 

deg 

Propulsion 

0.0*  kg 

ADCS 

Moderate  modifications  to  existing  design 

▼ 

Structure 

O.r  kg 

Number  of  thrusters 

0 

a 

Thermal 

1.5*  kg 

C&DH 

Nominal  new  design 

▼ 

TT&C 

2.7  kg 

Data  storage  capacity 

87184889.24*  Mb 

Propellant  mass 

O.o"  kg 

Downlink  data  rate 

2334000.00*  Kbps 

Power 

Moderate  modifications  to  existing  design 

▼ 

Number  of  spacecraft 

i 

r 

Propulsion 

Moderate  modifications  to  existing  design 

Physical  Dimension  Estimates 

Spacecraft  volume 

0.853"  m'3 

Structure 

Moderate  modifications  to  existing  design 

▼ 

Solar  array  area 

5.787*  tnC2 

Launch  Information 

Aperture  diameter 

0.260"  m 

Number  of  launches 

r 

Thermal 

Moderate  modifications  to  existing  design 

▼ 

Cost  per  launch 

14.0*  SM 

TT&C 

Moderate  modifications  to  existing  design 

▼ 

Power  Estimates 

Payload  power  (with  margin) 

0.3*  w 

Operations  Information 

BOL  power 

243.2"  W 

Mission  duration 

7  yrs 

EOL  power 

217.4*  W 

Number  of  hits 

42'" 

Average  power 

70.1*  W 

FEE  -  burdened  rate 

160.0  SK 

Battery'  capacity 

SA  A-hr 

Learning  curve  slope 

95.0H* 

Figure  13.  Cost  Estimate  Inputs 
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USCM  7th  Edition 

SSCM 

SSCM  (Ver  7.4)  ' 

SSCM  (\'er  8.0)  " 

(SMAD.  Tables  20-4  &  20-5) 

(SMAD,  Table  20-6) 

(RSMC,  Table  8-4) 

(RSMC,  Table  8-5) 

(FY00-SM) 

(FY00-SM) 

(FY00-SM) 

(FY00-SM) 

Payload 

$42,284 

S2.956 

$4,346 

$4,112 

Spacecraft  Bus  (Total  Estimate) 

* 

S4.961 

$4,686 

S10.864 

S10.281 

Spacecraft  Bus  (Sum  of  Components) 

$7,642 

$10,850 

S10.864 

S10281 

ADCS 

SI. 490 

S1.46S 

SI. 999 

SI. 892 

C&DH 

S1.784 

$2,193 

SI. 847 

S1.74S 

Power 

$3,098 

$4,573 

$2,531 

S2295 

Propulsion 

S0.000 

SO.SOO 

$0,913 

S0.864 

Structure 

$0,017 

S0.295 

S1.98S 

S1.SS1 

Thermal 

SO. 184 

$0266 

S0217 

S0206 

TT&C 

SI. 069 

$1254 

SI. 369 

SI  295 

Integration,  Assembly,  &  Test 

SS.952 

$1,027 

S1.510 

$1,429 

Program  Level 

S17279 

$1,692 

S2.488 

S2.354 

Ground  Support  Equipment 

$7259 

$0,488 

$0,717 

$0,679 

Launch  Integration  and  Early  Orbit  Ops  Suppon 

S0.418 

$0,451 

$0,663 

$0,627 

Total  Cost  (using  S/C  Bus  -  Total  Estimate) 

S81253 

S11.300 

S20.588 

S19.482 

Total  Cost  (using  S/C  Bus  -  Sum  of  Components  Estimate) 

S83.934 

S17.465 

S20.588 

S19.482 

Total  Cost  (using  weighted  average  of  S/C  Bus  estimates) 

S81246 

S13.976 

S20.588 

S19.482 

Figure  14.  Space  Segment  Cost  Comparison 
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